Bridging the gulf: a common intermediate language for ML and Haskell 



Simon Peyton Jones John Launchbury 

University of Glasgow and Oregon Graduate Institute Oregon Graduate Institute 

Mark Shields Andrew Tolmach 

University of Glasgow and Oregon Graduate Institute Portland State University 



Abstract 



Compilers for ML and Haskell use intermediate languages 
that incorporate deeply-embedded assumptions about order 
of evaluation and side effects. We propose an intermediate 
language into which one can compile both ML and Haskell, 
thereby facilitating the sharing of ideas and infrastructure, 
and supporting language developments that move each lan- 
guage in the direction of the other. Achieving this goal with- 
out compromising the ability to compile as good code as a 
more direct route turned out to be much more subtle than 
we expected. We address this challenge using monads and 
unpointed types, identify two alternative language designs, 
and explore the choices they embody. 



1 Introduction 



Functional programmers are typically split into two camps: 
the strict (or call-by-value) camp, and the lazy (or call-by- 
need) camp. As the discipline has matured, though, each 
camp has come more and more to recognise the merits of the 
other, and to recognise the huge areas of common interest. 
It is hard, these days, to find anyone who believes that lazi- 
ness is never useful, or that strictness is always bad. While 
there are still pervasive stylistic differences between strict 
and lazy programming, it is now often possible to adopt lazy 
evaluation at particular places in a strict language (Okasaki 
[1996]), or strict evaluation at particular points in a lazy one 
(for example, Haskell's strictness annotations (Peterson et 
al. [1997])). 

This rapprochement has not yet, however, propagated to 
our implementations. The insides of an ML compiler look 
pervasively different to those- of a Haskell compiler. Notably, 
sequencing and support for side effects and exceptions are 
usually implicit in an ML compiler's inlcrinccliatc language 
(IL), but explicit (where they occur) in a Haskell compiler 
(Launchbury & Peyton Jones [1995]). On the other hand, 
thunk formation and forcing are implicit in a Haskell com- 
piler's intermediate language, but explicit in an ML com- 
piler. These pervasive- differences make it impossible to 
share code, and hard to share results and analyses, between 
the two styles. 

To say that "support for side effects are implicit in an ML 
compiler's IL" (for example) is not to say that an ML com- 
piler will take no notice of side effects; on the contrary, an 
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ML compiler might well perform a global analysis that iden- 
tifies pure sub-expressions i I hough in practice lew do). How- 
ever, one might wonder whether the analysis would discover 
all the pure sub-expressions in a Haskell program translated 
into the IL. In the same way. if an Ml. program were trans- 
lated into a Haskell compiler 's IL. the latter might, not dis- 
cover all the occasions in which a function argument was 
guaranteed to be already evaluated. This thought motivates 
the following question: aridd we. design a common compiler 
intermediate language (IL) that 'would serve equally well for 
both strict and lazy languages? The purpose of this paper is 
to explore the design space for just such a language. 

We restrict our attention to higher order, polymorphically 
typed intermediate- language's. There is considerable interest 
at the- moment in type-directed cemipilat ion for peJvmeuphie 
languages, in which type information is maintained accu- 
rately right through compilation and even on to run time 
(Harper t v Meerrise-tt [1995]: Sliao cV Appel [1995]: Tarelili e-l, 
al. [1996]). Hence we focus on higher order, statically typed 
source languages, representee! in this paper by ML (Milner 
& Tofte [1990]) and Haskell (Peterson et al. [1997]). 

At first we expected the design to be relatively straight- 
forward, but we discovered that it was not. In particular, 
making sure that the IL has good operational properties for 
both strict and lazy languages turns out to be rather subtle. 
Identifying these subtleties is the main contribution of the 

• We employ rnonndi to express and de-limit state-, in- 
put/output, and exemptions (Section 3). Using mon- 
ads in this way is now well known to theorists (Moggi 
[1991]) and to language designers (Launchbury & Pey- 
ton Jones [1995]: Peyton Jones «V Waelle-r [1993]; 
Waeller [1992a]). but. with one exee-ption 1 , no compiler 
that we know has monads built into its intermediate 
language. 

• We- employ unpointed lypts to express (lie- iele-a that 
an expression cannot diverge (Section 3.1). We show 
that the straightforward use of unpointed types does 
not leael to a gooel implementation (Section 3.G). This 
leads us to explore two distinct language designs. The 
first. C\ . is mathematically simple-, but cannot he- com- 
piled well (Section 3). An alternative design, £2, adds 
operational significance tee unpointed typos, by guar- 
anteeing that a variable- e>f unpointe-el type- is evaluated 
(Section 4); this means £2 can be compiled well, but 
weakens its theory. 

• We identify an interactiem betwe-en unpointeel types, 
polymorphism, and recursion in £1 (Section 3.5). In- 
terestingly, the problem turns out to be more e-asilv 
solved in £ 2 than d (Section 4.2). 



Personal communication, Nick Benton, Persimmon IT Ltd, 1997. 



None of these ingredients arc new. Our contribution is to ex- 
plore the interactions of mixing them together. We emerge 
with the core of a practical IL that has something to offer 
both the strict and lazy community in isolation, as well as 
offering them a common framework. Our long-term goal is 
to establish an intermediate language that will enable the 
two communities to share both ideas (analyses, transforma- 
tions) and systems (optimisers. code generators, run-time 
systems, profilers, etc) more effectively than hitherto. 



2 The ground rules 

We seek an intermediate language (IL) with the following 
properties: 

• II. rnusl be possible In liunslali both, (cure) ML and 
Haskell into the IL. Extensions that add laziness to 
ML, or strictness to Haskell, should be readily incor- 
porated. We make no attempt to treat ML's module 
system, though that would be a desirable extension. 

• In order to accommodate ML and Haskell the IL's 
type system must support polymorphism. This ground 
rule turns out to have very significant, and rather 
unfortunate, impact upon our language designs (Sec- 
tion 3.5), but it seems quite essential. Nearly all exist- 
ing compilers generate polymorphic large! code, and 
although researchers have experimented with compil- 
ing away polymorphism by type specialisation (Jones 
[1994]; Tolmach & Oliva [1997]), problems with sepa- 
rate compilation and potential code explosion remain 
unresolved. 

• The IL should be explicitly typed (Harper & Mitchell 
[1993]). We have in mind a variant of System F (Gi- 
rard [1990]), with its explicit type abstractions and 
applications. The expressiveness of System F really 
is required. For example, there are several reasons 
for wanting polymorphic arguments to functions: the 
translation of Haskell type classes creates "dictionar- 
ies" with polymorphic components; we would like to be 
able to simulate modules using records (Jones [1996]); 
rank-2 polymorphism is required to express encap- 
sulated state (Launchbury & Peyton Jones [1995]); 
and dal,a-sl,ruol.iir<! fusion (Gill. Launchbury fc Pey- 
ton Jones [1993]). 

IL programs can readily be type-checked, but there 
is no requirement that one could infer types from a 
type-erased [L program. 

• The IL should have a single well-defined semantics. On 
the face of it, compilers for both strict and lazy lan- 
guages already use a common language, namely the 
lambda calculus. But this similarity is only at the 
level of syntax; the semantics of the two calculi differ 
considerably, in particular, the code generator from 
a strict-language compiler would be completely unus- 
able in a la/y-laiiguage compiler, and vice versa. Our 
goal is to have a single, neutral, semantics, and hence 
a single optimiser and code generator. 

• ML (or Haskell) programs thus compiled should be 
as efficient as those compiled by a good ML (resp. 
Ilei.skill) enrn.pi.hr. In other words, compiling through 
the common II. should not impose any unavoidable effi- 
ciency penalty, either by way of loss of transformations 
(especially when starting from Haskell) or by way of 



less efficient basic: evaluati n< 1 (especiall hen 
starting from ML). Indeed, our hope is that we may 
ultimately be able to generate better code through this 



3 C\, a totally explicit language 

It is clear that the IL must be explicit about things that are 
implicit in "traditional" compiler ILs. Where are these im- 
plicit aspects of a "traditional" IL currently made explicit? 
Answer: in the denotational semantics of the IL. For ex- 
ample, the denotational semantics of a call- by- value lambda 
calculus looks something like this 2 

£[ei e 2 jp= (Elei.jp) b, if a = b ± 
_L, if a = _L 

where a = £{e2]p 

Here, the two cases in the right-hand side deal with the pos- 
sible non-termination of the argument. W hat is implicit in 
the IL - the evaluation of the argument, in this case - be- 
comes explicit in the semantics. An obvious suggestion is 
therefore to make the IL reflect the denotational semantics 
of the source language directly, so that everything is explicit 
in the IL, and nothing remains to be explicated by the se- 
mantics, 'this is our first design, £,. 

Figure 1 gives the syntax and type rules for C\. We note 
the following features: 

• As a compromise in the interest of brevity all our 
formal material describes only it simply-typed calcu- 
lus, although supporting polymorphism is one of our 
ground rules. The extensions to add polymorphism, 
complete with explicit type abstractions and applica- 
tions in the term language, are fairly standard (Harper 
cV Mitchell [1993]; Peyton Jones [1996]; Tarditi et al. 
[1 990] )• However, polymorphism adds some extra com- 
plications (Section 3.5, 3.6). 

expressions for the sake of simplicity, being content 
with pairs and selectors. 

• let is simply very convenient syntactic sugar. It is not 
there to introduce polymorphism, even in the polymor- 
phic extension of the language; explicit typing removes 
this motivation for let. 

• letrec introduces recursion. Though we only give it 
one binding here, our intention is that it should ac- 
commodate multiple bindings. We use it rather i han 
a constant fix because the latter requires heavy en- 
coding for mutual recursion that is not reflected in 
an implementation. We discuss recursion in detail in 
Sec-lion 3.5. including I he unspecilied side condition 
mentioned in the rule. 

• Following Moggi [1991], we express "computational ef- 
fects" such as non-ierminalion. assignment, excep- 
tions, and input/output — in monadic form. The type 
M r is i he type of .1/-compulalious ret iirning a value 
of type t. where M is drawn from a fixed family of 
monads. The syntactic forms letM and retM are 

2 We use the following standard notation. If T is a complete partial 
order (CPO). then the (TO T . pronounced "T lifted", is defined 
thus: 7j_ = {a ± | a G T} U {_!_}, with the obvious ordering. 



2 



Types t 
Terms 



Constants k 
Monads M 



Int | ti->t 2 I 0 I (Tl,T 2 ) 
Ref t | M t 



= fst I snd | new | rd | wr | liftToST 

I 0|1|2|...| + |-|... 
= Lift | ST 



(VAR) 
{PAIR) 
(APP) 
(LAM) 
(LET) 
(REC) 

(LETM) 

(RET) 

(FST) 

(SND) 

(PLUS) 

(NEW) 

(RD) 

(WR) 

(LIFT) 



32) : (ti,t 2 ) 
->p ? h e 2 : 



? , x : t h ei : t ?,i : t he2 : (i 
...phis ;i side o mi litii m . .. 
? h letrec x:r = ei in e 2 : p 

h ei : M n ? , I : Ti h e2 : M T2 
? h let m x:n < _ ei in e 2 : M t 2 



? h fst : (n ,r 2 ) - 
? h snd : (n ,r 2 ) - 



' h liftToST : Lift 7 



T : Type CT£> 



T[ti->t 2 
T[(ri,r 2 ) 
7~[() 
T[Lif t r 
T[ST t 
T[Ref r 
State 



T[n] -»■ T[r 2 ] 
Tin] x T[r 2 ] 



= TWi 

= State 

= AT 

= N-^\j T n 



(Tlr 



£ : Term-r — > Env 
£{x P 

£\k 

£[ei C2 
£[\x.e 
£[(ci.e a ) ! 
£[let x:r = ei in e 2 



*T[r] 



, (£[ ei ]p) (£[e 2 ]p) 
1 p = \y.£[e\p[x := y] 
(f[ei]p,f[e 2 ]p) 

^ • , .l<,]p[. C: =f[ ei ]p] 

£T[letrec x:r = ei in e 2 p = f [e 2 l(r«-[a-, r.j]p) 
f [letjif x:r<-ei ine 2 p = Hnd M (£[eijp) 

(Xy.£[e 2 ]p[x := y]] 
£[ret M e]p = umtu (£\e\p) 

re4x, ei ]p = fix(\p'.p[x :=£le 1 jp']) 



fst (a,b) 








snd (a,b) 




b 




bindLift m k 




±, 


if m = ± 






ka, 


if m = oj_ 


unitLift x 




x± 




bindsT mk s 




±, 


ifm* = l 






k r s', 




unitsT m s 




(m,s) ± 








(r,s[r^v]) L 


where r 0 dom(s) 


r s 




(s r,s) ± , 


if r 6 dom(s) 








otherwise 






((Ur->»]) ± 


if r 6 dom(s) 






_L, 


otherwise 


liftToST m s 




(r,s)±, 


if m = r± 






±, 


otherwise 



Figure 1: Syntax and type rules for d 



the hind and unit coinhinators of the inonad M. The 
only two monads we consider for now are the lifting 
monad, Lift, and the combination of lifting with the 
state transformer monad, ST. It is a straightforward 
extension to include the monads of exceptions and in- 
put/output as well. 

This use of monads appears to contradict our goal that 
Ci should have a trivial semantics. We discuss the 
reasons for this decision in Section 3.4. 

Figure 2 gives the semantics of The semantic function 
T gives the meaning of types. If it looks somewhat boring, 
that is the point! The function arrow in C\ is interpreted by 
function arrow in the underlying category of complete par- 
tial orders (CTO), product is interpreted by (categorical, i.e. 



Figure 2: Semantics of L\ 



un-lifted) product, and integers are interpreted by the inte- 
gers. (If £1 were expanded to have sum types, they would 
be interpreted by (categorical, separated) sums.) Lastly, 
each monad is specified by an interpretation. The monad 
of lifting is interpreted by lifting, while a. state transformer 
is interpreted by a function from the current "state" to a 
result and the new state. The "state" is a finite mapping 
from location identifiers (modeled by the natural numbers, 
AO to their contents. 

The semantic function £ gives the meaning of expressions. 
Again, many of its equations are rather dull: application 
is interpreted by application in the underlying category, 
lambda abstraction by functional abstraction, and so on. 
The semantics of the two monads is given by their bind and 
anil functions. From the semantics one can prove that both 
3 and // are valid with respect to the semantics, and that 
monadic expressions admit a number of standard transfor- 
mations, given in Figure 3. 
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(Ml) 


let M a;< re 






let 2J:r e 


in . & 






(Mi) 


letM x <- (letM y<~ei i 


n e 2 ) in 




= letM y<-e 


in (let M x<-e 2 in 


b) 


y % jv{b) 


(M3) 


letM ^ <- (let y = ei i 


n e 2 ) in 




— let y-ei i 


i (letM x <- e 2 in 6) 




y 0 fv{V) 




let M a; <- (letrec ^~ e ^ i 


n e 2 ) in 




— letrec y-e 


i in (letM x <- e 2 ir 


b) 


y 0 fv(b) 


(M5) 
















(M6) 


let x = e 


n retM 


b 


= retM (let 


c = e in b) 







Figure 3: Monad transformations 



Types S, T 
Haskell only 



Haskell only 
Integers i 



pair M N | fst M | snd M 
new M rd M wr M N 
letsT x-.T-^M in iV | ret ST M 



Va.a ->• Ref a 
Va.Ref a ->• a 
VaRefa^a^Q 



"Haskell" constants 
: Va.a — > ST (Ref a) 
: Va.Ref a ->• ST a 
: Va.Ref «—>■«—>■ ST () 



3.1 Termination and non-termination 

As we have mentioned, the interpretation of a type in C\ 
is a complete partial order (CPO). However, the interpreta- 
tion of a type is not necessarily a pointed CPO; that is, the 
C'PO does not necessarily cont ain a hot t orn element . For 
example, the (lata type of integers. Int. is interpreted by 
the unpointed CPO of integers, Z. That is, if an expression 
lias type Int. then it denotes an integer, and cannot denote 
a non-terminating computation. How, then, do we express 
the type of possibly-diverging integer- valued computations? 
As we have seen, Ci has an explicit type constructor for 
each monadic (i.e. computation) type, of which lifting is 
one. To express the type of a possibly-diverging integer we 
use the lifting monad. A possibly-di\ erging integer- valued 
expression therefore has type Lift Int. 

So £i's type system can distinguish surely-terminating ex- 
pressions from possibly-diverging ones. The main reason 
for making this distinction in the type system is so that we 
can express the idea that a function takes an evaluated argu- 
ment. The £i lambda abstraction \x:Int.e expresses that 
x cannot possibly be X. and so is a suitable translation of a 
lambda abstraction from a call-by-value language. On the 
other hand \x:Lift Int.e expresses that x might perhaps 
be J., which fits a call- by-name or call-by-need language. 

A second motivation for distinguishing pointed types from 
unpointed ones is that some useful program transforma- 
tions that are not valid in general, hold unconditionally 
when one has more control over pointedness. Several re- 
searchers have explored languages that employ a distinc- 
tion between pointed and unpointed types (Howard [1996]; 
Launchbury k. Paterson [1996]), and others have explored 
pure languages without pointed types altogether (Cockett 
& Fukushima [1992]; Hagino [1987]; Turner [1995]). The 
presence of unpointed types has consequences for recursion, 
as we discuss in Section 3.5. 



Figure 4: Syntax of S 



community has been using monads very effectively to isolate 
and encapsulate stateful computations and input /output 
within pure, lazy programs (Launchbury & Peyton Jones 
[1995]: Pevton Jones. Cordon k. Fume [1996]; Peyton Jones 
& Wadler [1993]: Wadler [1992b]). Nevertheless, there are 
surprisingly subile design choices to make, as we discuss in 
Section 3.4. 



3.2 Stateful computations 

In a similar way, we use the ST monad to express in the type 
system the distinction between pure and stateful computa- 
tions. For example, an expression of typo Lift Int denotes 
a pure (side-effect free), albeit possibly-divergent, computa- 
tion; on the other hand, and expression of type ST Int de- 
notes a compulation that might diverge", or might perform 
some side effects on a global state and deliver an integer. 
Further monads can readily be added to model exceptions, 
or continuations, or input/output. 

This use of monads is well known. Moggi pioneered the 
idea of using monads to encapsulate computations (Moggi 
[1991]; Wadler [1992a]). The lazy functional programming 

3 ST combines lifting with state. It would be possible to separate 
the two. as we discuss in Sen ion 7. 



3.3 Translating ML and Haskell into A 

Before discussing its design any further, we first emphasise 
£i's role as a target for both strict, stateful, and pure, lazy 
languages by giving translations front both into Ci ■ figure 4 
gives the syntax of a tiny generic source language, 5. We 
regard S as a prototype for either ML or Haskell, by giving 
it a strict or la/v interpretation respectively. In either case, 
S is assumed to have been explicitly annotated with type 
information by a type inference pass. 

The constants pair, fst, snd have the same (obvious) 5 
types in both interpretations. The constants new, rd, wr 
create, read, and write a mutable variable. Unlike pair, 
their types dilfer in the two interpretations, as Figure 1 
shows. In the la/v interpretation their types explicitly in- 
volve the source-language ST monad, and S also includes 



A4[Int] 


= Int 


M[S*T} 


= (A4[S],A4[rp 


M[()J 


= 0 


M[S ->T] 


= M[SJ -> ST VW[T] 


A4[Ref S] 


= Ref (A4[S]) 


M[xJ 


= ret ST x 




= ret ST i 


,V1[.U A'] 


= let ST /<-A4[M] in 




let ST a<-M[NJ in 






M\\x:T.MJ 


= ret ST (U:X[T].X[A/]) 



M[\et x:T = MinN} 

= let ST x:A4[T]<-A/([M] in , VI [AT] 
.A/f [letrec / : S -> T = Xx : S.M in NJ 
= letrec /:X[S T] = \x : A/f[S].A4[M] in M[NJ 
.A/f [pair M NJ = let ST a<-X[M] in 
let ST b<-M[N] in 
ret ST (a, 6) 
. . . and similarly wr, + 
M[tst Mj = let ST a<~M[Mj in 
retsT fst a 

. . . and similarly snd, new, rd 



ft [Int] = Lift Int 
ft[S*T] = Lift (ft[S],ft[T]) 
ft[()] = Lift () 
ft[S — > T] = ft [5] -> ft[T] 
ft [ST T] = ST (ft[T]) 
ft [Ref 5] =Lift (Ref (ft[S])) 

ftW = x 
ftp] = ret Lift i 
HIM NJ = ft[M] ft [AT] 
ft[Ax:T.M] = \x:ft[T].ft[M] 
ft [let z:T = M in NJ = let sc:ft[T] = U{MJ in ft[AT[ 
ftpetrec x:T = M in A<] 

= letrec x:U{TJ=U[MJ in ft [TV] 
ft[pair M NJ = ret Lift (ft[JW] ,ft[AT]) 
ft[M + AT] = letLift a<-ft[M] in 
let Lilt 6<-ft[JV] in 
ret Lift ( + ° M 
ft[fst M] = let Lif t a<-ft[M] in fst a 
. . . similarly snd 
ft[wr M NJ = let ST a<-liftToST ft[M] in 
W r a ft[/V] 
. . . similarly new. rd 

ftpetsx x:T<-MinJV] 

= let ST x:ft[T]<-ft[M] in ft [AT] 
ft[ret ST M] = ret ST ft[M] 



Figure 5: Translations of "ML" and -Haskell" into Ci 



letsT and retsT, the unit and bind operations for ST. Mod- 
ulo syntax, this is precisely how Haskell expresses stateful 
computation (Launchbury K: Peyton Jones [1995]). 

Then Figure 5 gives two translations of 5 into 

• The "ML" irnnslniiou. M '• gives the source language 
a stateful. strict, semantics. The result of a term trans- 

4 The translation given here introduces quite a few "administrative 



lated by M is a computation in the ST monad, and 
functions also return computations in ST. That is, if 
the ML tvpe svstem considers that ? he: r, then 
MpJ ^M[eJ :STM[r]. 

The rule for application uses letgj to evaluate both 
the function and its argument, and to sequence any 
state changes they contain, before applying the func- 
tion to the argument. In expressions produced by 
the M translation, each variable is bound to a non- 
monadic type: that is. any effects (state or non- 
terminal ion) are performed before binding the vari- 
able. When a variable, lambda, or pair is translated 
we simply return the value using retgj. Lastly, a re- 
cursive ML declaration can only bind a function: hence 
the rule for letrec. 

• The "Haskell" translation, ft, gives the source lan- 
guage (minus the state-changing operations) a pure, 
non-strict semantics. A key difference from the ML 
translation is that the Haskell translation of data, 
types, such as integers, pairs, and lists, are lifted, be- 
cause Haskell allows values of these types to be recur- 
sively defined. Unlike the ML translation, the transla- 
tion of Haskell's function type does not need to have 
an explicit Lift on the codomain. Nor does the trans- 
lation ft necessarily return a Lift computation: if the 
Haskell tvpe svstem concludes that ? h c : r then 
ft[?] bft[e] :ft[r]. 

ft translates Haskell's ST-monad computations di- 
rectly into £i's ST monad, just as you would hope 5 . 
The only tiresome point is that the first argument of 
wr has source-language type Ref r, and hence has 
Ci type Lift (Ref ft[r]). It must therefore be lifted 
into the ST monad using liftToST so that it can be 
evaluated in the ST monad. 

It is interesting to compare the two type translations. M. 
uses exactly the call-by- value translation of Wadler [1992a], 
with the computational effect at the end of the function 
arrow. On the other hand ft does not use Wadler's call-by- 
name translation, as one might otherwise expect. Indeed, 
there is no monadic effect in the translation of function types 
at all; instead the Lift monad shows up in the translation 
of data types. 

This translation of Haskell function types assumes that 
\x.bot and bot, where bot has value J_, denote the same 
value in Haskell. Recent changes to Haskell are likely to al- 
low these values to be distinguished, forcing a lifting of func- 
tion types, and hence a more gruesome encoding of function 
application. 



3.4 Why not encode the monads? 

We have said that £i is meant to make everything explicit, 
so that there is nothing to be said when giving its semantics. 
In apparent contradiction, we made the semantics of the 
monads implicit — that is, explained only by the semantics 
of C\. Why. for example, did we not make the ST monad 
explicit by representing a value of tvpe ST r as a state- 
transforming function in £i, and representing letg T and 

redexes": a slightly more (-[implex Inundation can avoid thorn (Sahiy 
fe Wadler [1996]). 

5 We do not treat the runST encapsulator of Launchbury & Pey- 
ton Jones [1995] here, but it is easy to do so. 
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retsT using the other L\ forms? For example, instead of 
the Ci term 

letsT x<- e in b 
we could write the Ci term 

bindST e (Vs. 6) 
where bindST is defined (directly in £1) as follows 

bindST = \m k s.let p = m s in k (fst p) (snd p) 

Here, the state passing is made explicit, but the state itself 
is still abstract, supporting the new, read and write oper- 
ations. This is the approach advocated by Launchbury & 
Peyton Jones [1995, Section 9]. It has the notable advantage 
that we can simplify Ci by getting rid of letM and retjy 
entirely. 

We do not adopt that approach here, for thre 



h (Lift r) pointed 

h (ST t) pointed 

h Ti pointed 
I- (t2 -> n) pointed 

- n pointed h r 2 pointed 
I- (n ,t 2 ) pointed 



Figure 6: Rules for pointed types 



i be constructed a 



V type. But that is not so. 



» Encoding the monad in purely functional terms is a 
reasonable way of giving its semantics, but it may not 
be a reasonable way of giving iis nn.ph mi nlnli.on. Con- 
sider, for example, the monad of exceptions in a strict 
language. The functional encoding would perform a 
conditional test whenever a possibly-exceptional value 
was bound; but the expected implementation is stack- 
based with no tests. Instead, a whole chunk of stack- 
is popped when an exception is raised. Keeping the 
monad explicit in L\ allows the code generator to gen- 

» Even where an ellieienl code-general ion strategy does 
exist, its correctness may be fragile. For exam- 
ple, Launchbury & Peyton Jones [1995] describes an 
update-in-place implementation of the primitive op- 
erations (read and write) in the state monad. How- 
ever, that implementation is only correct if the state 
is single-threaded. That is certainly the case in the 
terms produced by M, but it might not remain the 
case after performing L\ transformations. For exam- 
ple, a /9-expansion might duplicate the state. 
It may be possible to preserve the single-threadedness 
of the state by limiting the transformations performed 
on the £i program. (For example, we believe that 
using only transformations that are correct in a call by 
need calculus is sufficient (Sabry [1997]).) Even where 
this is true, it creates a complicated proof obligation. 

» There may be useful transformations available that are 
specific to a particular monad (for example, swapping 
the order of non-interfering assignments), but which 
become inaccessible, or hard to spot, when expressed 
in a purely-functional encoding of the monad. 



We find these reasons compelling. On the other hand, we 
were concerned that by not translating the monadic code 
into a core of L\ we might lose valuable transformations. So 
far, however, we have found no transformation that cannot 
be expressed in the monadic version of C\. providing the 
standard monad laws are implemented (Figure 3). 



3.5 Recursion in C\ 

One consequence of our decision to allow a type to be mod- 
eled by an unpointed CPO is that we have to take care 
with recursion. The rule (REC) in Figure 1 suggests that a 



Such a recursive definition is plainly nonsense, because Int 
is an unpointed type and has no bottom element, so there 
might be no solution, or many solutions, to the recursive 
definition. We can only do recursion over pointed CPOs! 6 

How, then, can we make sense of recursion? One solution 
is to link recursion to the Lift monad, since Lift adds a 
bottom to its argument domain: 



This solut 
type: 



very satisfactory. For a start, it cannot 



let 



c f = \x. 



because the type of a lambda abstraction has the form 
t —¥ p, not Lift r, and lifting all functions raises the spec- 
tre of having to force the definition on each recursive call. 
Nor can it type recursive definitions of ST computations. 
Furthermore, this loss of expressiveness is completely un- 
necessary, since a function type whose result type is pointed 
is itself pointed; and any ST computation is pointed. The 
right solution is to fix (REC) by adding a side condition that 
r must be pointed: 



(RECb) 



?,x : t h e 2 : p 
h t pointed 
? h letrec x:r = ei in e 2 : 



Figure 6 gives rules for determining when a type is pointed. 
Unfort unal elv. the extension to a polymorphic, lytic system 
is problematic: is the type a pointed or not? There are three 
possible choices: 

• We could decide that type variables can only range 
over pointed types. This is precisely the restriction 
proposed by Peyton Jones & Launchbury [1991], but 
it is unacceptable in our IL because we expect (the 
translations of) most ML data types to be unpointed. 
For example, an ordinary, non-recursive polymorphic 
function such as the identity function could not be 
applied to both 3 and retrift 3, because one has a 
lifted type and one does not. 



sion (for. 
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• We could allow type variables to range over all types, 
but prohibit recursion at a type variable. This would 
irritatingly reject recursive functions whose result type 
is a type variable, such as the function nth that selects 
the n'th element from a list. 

nth : Va.Int -> (List a) -> a 

• Alternatively, we could employ qualified universal 
quantification, where type variables at which fixpoints 
are taken arc explicitly qualified: 

nth : Mae Pointed .Int -> (List a) -> a 

Launchbury & Paterson [1996] elaborate on this idea. 

Since the first two choices are untenable, we conclude that 
adding polymorphism to a language with both recursion and 
unpointed types, requires the use of qualified universal quan- 
tification. 



3.6 Controlling evaluation in C\ 

While £| seems to be quite suitable from a theoretical point 
of view, it suffers from a serious practical drawback: £1 is 
vague about the timing and degree of evaluation. Consider 
the Ci expression: 

let x : r = e in f x 

What, code should the code generator produce for such an 
expression? 

• An ML compiler writer would probably expect the 
code to cnalaali: the right-hand side of the let. and 
then call f passing the value thus computed. But this 
eager strategy is incorrect in general if e diverges, and 
f does not evaluate its argument, as a quick glance at 
Figure 2 will confirm. 

• A safe strategy is to build a thunk (suspension) for 
the right-hand side, bind x to this thunk, and call f 
passing the thunk to it. That is precisely what the 
code generator for a lazy language would do. 

Now suppose that we are compiling code for f, and that 
f has type Int -> Int. The major motivation for distin- 
guishing Int from Lift Int was to allow the compiler to 
treat values of type Int as certainly-evaluated, just as a 
strict -language compiler would assume (Seciion 3.1). It is 
unacceptable for f to test whether its argument is evaluated: 
such a choice would guarantee that no ML compiler would 
use this intermediate language! Alas, the safe strategy for 
preparing the f 's argument does indeed pass an unevaluated 
thunk. so f must be prepared for this eventuality. 

Can we instead use a hybrid strategy? 

• A hybrid strategy for compiling let expressions might 
use the type of the bound variable to decide what to 
do: for types whose values are sure to converge (such 
as Int) it can evaluate the right -hand side eagerly, oth- 
erwise it can build a thunk. This strategy works for 
a simply-typed language but fails (again!) when we 
introduce polymorphism. What is the code generator 
to do with a let that binds a value of type a? Either 
the instantiating type must be passed as an argument, 
or we must have two versions of the code, one for ter- 
minating types and one for possibly-diverging ones. 



We regard these complications as a very serious (and far 
from obvious) objection to using £i for operational pur- 
poses. 



3.7 Summary 

We expected it to be a routine matter to translate both 
Haskell and AIL into a common language built directly on 
top of the standard mathematics for programming-language 
semantics. To our surprise it was not. as Sections 3.5-3.6 
describe. 

£i may still be quite useful as a kernel language for rea- 
soning about programs. However, as Section 3.6 has shown, 
it is unsuitable as a compiler intermediate language. Thus 
motivated, we now turn our attention to a second design 
that is more suitable as an IL. 



4 L'2, a language of partial functions 

Our second design starts from the problem we described in 
Section 3.6. Operationally, it is essential to be able to con- 
trol exactly when evaluation takes place, so that the recipi- 
ent of a value knows for sure whether or not it is evaluated. 

Since we want to control what evaluation is done when, the 
obvious thing to do is to make let (and, of course, function 
application) eager. That is, to evaluate let i:r = ein b 
one evaluates* <>, binds it, to x, and then evaluates b. (We 
use the operational term "eager", rather than the semantic. 
term "strict" because the latter does not mean anything if 
the type of e has no bottom element.) How, then, are we to 
translate the lets and function applications of a lazy lan- 
guage? There is a standard way to do so, namely by making 
the construction and forcing of t hunks explicit (Friedman k. 
Wise [1976]). This is what we do in £ 2 . 

Figure 7 gives the syntax and extra type rules for £ 2 . There 
is now only one monad, ST; the Lift monad is now implicit 
in the semantics of £2 so that let and function application 
can be eager. There is a new syntactic form, <e>, that sus- 
pends the evaluation of < ■ and a new- constant, force, that 
forces the suspension returned by its argument. There is 
one new type, <p>, which is the type of <e> if e has type p. 
The two new type rules, (DELAY) and [FORCE) are just 
as you would expect. 

Another new- feat lire is that types are divided into value 
types, r, and computation types, p. Intuitively, an expression 
has a computation type, while a variable is always bound to 
a value type. Another way to say this is that the typing 
judgement now has the form 

{x 1 :r 1 ,...,x n :r n }\-e:p 

The type rules of figure I apply unchanged, because we 
carefully used r and p in the right places, although they were 
synonymous in £,. Function arguments and the right-hand 
sides of let(rec) expressions all have value types, and are 
evaluated eagerly. This separation of value types from com- 
putation types neatly finesses the awkward question of what 
it means to "evaluate" an argument computation without 
also "performing" it. which caused us some heart-searching 
in earlier un-stratified versions of £ 2 . For example, the ex- 
pression (f (read r)) is ill-typed, and hence we do not 
have to evaluate (read r) without also performing its state 
changes. Indeed, expressions of type ST r can only occur as 
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Computation types p ::= M r r 

Value types r ::= Int | r->p | () | (ri ,r 2 ) 
| <p> Ref t 


Terms e ::= x | | ei e 2 | Vr.e | (ei,e2) | <e> 
| let a;:r = ei in e 2 
| letrec x:r = pv in e 

let M a: : r <- ei in e 2 ret M e 


Monads M ::= ST 
VaZuea v ::= z | ft | \x:r.e 


\<e>\( Vl ,v 2 ) 


The type rules from Figur 


1, plus. . . 


(DELAY) ?h< h J 


: P 
:<p> 


(FORCE) ? h force : 


<p> -> p 



Figure 7: Kxtra syntax and type rules for C-> 



The translation .Vf from ML to £ 2 
is lexluallv the same as in Figure 5 



Wpnt] = 
H[S * T] -- 

moi -- 

H[S -> Tj -- 
U[ST Tj = 
«[Ref 5] = 

W[x] = 

= 

7*[M iV] = 
U{\x:T.M\ -- 
:T = M iniV] = 

:T = M iniV] = 

ft [fst M = 
ftjpair M iV : = 
ft[M + N = 
ft[wr M N -- 



ft[let ST x : T <— M in iV] : 
ft[ret ST M] : 



«ft[S]>,< 

0 

<ft[S]> -> 
ST <ft[T]> 
Ref <ft[S]: 



ft[T]» 
HIT] 



ft [let i 
ft [letrec i 



U{Mj <H[Np 

Vr:<ft[T]>.ft[M] 

let x:<U[Tj> = <'H[Mj> in 

ft[/V] 

letrec a; : <ft[T]> = <ft[M]: 
in H[Nj 

force (fst ft[M]) 

«ft[A/]>,<ft[JV]» 

+ ft [A/] ft [TV] 

wr ft[M] ft[/V] 

. . . similarly new, rd 

let ST x:<ft[T]><-ft[M] 

in H[N] 

ret ST ft[M] 



Figure 9: Translations of "ML" and "Haskell" into £■> 



the right hand side of a let ST , the body of a function, or 
as the value of the whole program. Finally, when polymor- 
phism is introduced, type variables range over value types 
only- 
Figure 8 gives the semantics of £ 2 in full. The crucial point 



is that £ 2 's function type arrow is now interpreted as the 
CPO of partial function*, denoted and the semantic 

evaluation function £ takes an expression to a partial func- 
tion from environments to values. Many of the equations 
are defined conditionally. For example, the equation for 
£[ei e 2 ]p says that if both £[ei]p and £[e 2 ]p are defined 
then the result is just the application of those two values; 
otherwise there is no equation that applies for £[ei e 2 ]p, so 
it too is undefined. 

The <_> type constructor is modeled using lifting; the se- 
mantics of force and <_> move to and fro between lifted 
CPOs and partial functions. It may seem odd that we use 
two different notations — Lift r in £iand <r> in £ 2 — with 
the same underlying scmani ic model, namely lifting. The 
reason is that in £, we use lifting as a monad (with a bind 
operation, for example), whereas in £ 2 we use it to model 
t hunks (with a force operation but no bind). 

The entire semantics of £•_> could instead be presented in the 
CPO of total functions, using the isomorphism: 

S^T^S^T ± 

Which to choose is just a matter of taste. What we like 
about our presentation is that each £ 2 type constructor cor- 
responds directly to a single categorical type constructor, 
whereas in the alternative presentation the £ 2 function type 
gets a more "encoded" translation. Launclibury & I5a.ra.ki 
[1990] use partial functions in essentially the same way. 

The translation of "ML" into £ 2 is exactly the same as the 
translation of £i . The translation of "Haskell" is differ- 
ent, however, because we now have to be explicit about the 
introduction of t hunks (Figure 9). Concerning types, no- 
tice the use of the type constructor <_> on the arguments 
of functions and data constructors. Concerning terms, the 
thunk-former <_> is used for function arguments and the 
right-hand side of all let and letrec definitions. Thunks 
are evaluated explicitly, using force, when returning a vari- 
able or the result of fst or snd. 



4.1 Controlling evaluation in £2 

The main benefit of using £ 2 is that its semantics permit 
an eager interpretation of vanilla let: namely, "evaluate 1 the 
right-hand side, bind the value to the variable, and then 
evaluate the body". A consequence is that any variable of 
type other than <t>, or a type variable (which might be in- 
stantiated to <t>), is sure to be fully evaluated, just as in 
any ML implementation. 



4.2 Recursion in £2 

Another advantage of £ 2 is that we can solve our earlier 
difficulties with recursion (Section 3.5) without requiring 
bounded quantification. 

Firstly, we more or less have to restrict letrecs to bind 
only syntactic values, because we cannot eagerly evaluate 
the right-hand side. (Why not? Because we cannot con- 
struct the environment in which to evaluate it.) That in 
turn means that the meaning of the right-hand side is al- 
ways defined, which is why there is no side condition in the 
semantics of letrec. 

But Figure 7 furt her rest riot s t he right -hand side of a letrec 
to be a particular sort of syntactic value, a pointed value, or 
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Figure 8: Semantics of £ 2 



PValue. The syntactic category of PValues is chosen so 
that it can only denote a value from a pointed domain, and 
hence a letrec definition always has a least fixpoint. To see 
this, consider the forms that a PValue can take: 

• A lambda abstraction denotes a partial function, and 
the CPO of partial functions is always pointed; its least 
element is the everywhere undefined function. 

• A thunk <e>, where e : r, is drawn from the pointed 
CPO T[t] ± . 

Fortunately, the syntactic restriction of letrec does not lose 
any useful expressiveness. ML insists that letrecs bind only 
functions (which are PValues), while Haskell binds thunks 
(which are also PValues). So there is no difficulty with 
translating the recursion arising in both ML and Haskell 
into £ 2 . 



computations in ST must bo maintained, whereas let bind- 
ings can be re-ordered freely. Changing the order of evalua- 
tion is fundamental to several useful transformations, in- 
cluding common sub-expression, loop invariant computa- 
tions, all kinds of code motion (Peyton Jones, Partain & 
Sanios [199(5]). inlining, and strictness analysis (remember 
we may be compiling a lazy language into £i). To take a 
simple example, the following transformation is not in gen- 
eral valid for lets?, but is valid for vanilla let (assuming 
there are no name clashes): 

let x\ = ei in let x 2 = e 2 in b 

let x-2 = e 2 in let xi = ei in b 

Of course, one could do an effects analysis to determine 
which sub-expressions were pure, as good ML compilers do, 
. . . bur that is effectively just what the monadic type system 
records! 



4.3 Why not have just one monad? 

Now that we have eliminated the Lift monad, and made 
vanilla let eager, there is another question we should ask: 
why not give vanilla let the semantics of letsi, and elimi- 
nate the latter altogether? To put it another way, we have 
made eager evaluation implicit in the semantics of let: why 
not add implicit side effects as well? After all, the code gen- 
erated for letsi x<-e in 6 will be something like "the code 
for r followed by the code for b" . and that is just the same 
as the code we now expect to generate for let x = e in b. 

However, if we have just one form of let we lose valuable 
optimising transformations. In particular, the sequence of 
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5.1 C\ vs £ 2 

What have we lost in the transition from L\ to £ 2 , apart 
from a somewhat more complicated semantics? One loss is 
C\ "s ability lo describe typos whose values arc sure to termi- 
nate. If a £i function has type Int->Int then a call to the 
function cannot diverge: but the same is not true of £>. This 
does not have much impact on a compiler, but it make pro- 
grammer reasoning about C-> programs more complicated. 



Another important difference is that £2 has a weaker ft rule. 
£1 has full /3-conversion. That is, for any expressions e and 
6: 

let x = e ±nb = b[e/x] 

(A similar rule holds for application, of course.) In £ 2 . how- 
ever, P does not hold in general. A particular case of this is 
that if x is not mentioned in b then in £1 the binding can 
be discarded; in £ 2 the binding can only be discarded if the 
right-hand side is a value. 

However pv — a restricted version form of ft that allows 
only values to be substituted — is valid in £ 2 . Values are 
defined in Figure 7. and include variables, constants, and 
lambda abstractions, as usual. However, values also include 
thunks. Hence any Haskell ft reduction has a corresponding 
fiv reduction in its £2 translation. Thus, the restriction to 
Pv will not prevent a Haskell compiler from doing anything 
it can do in an implicitly la/v language with a full 3 rule. 

Thus far we have assumed a call-by-name semantics, in 
which we are content to duplicate arbitrary amounts of work 
provided we do not change the overall result. In practice no 
compiler would be so liberal; we desire a call-by-need se- 
mantics in which work is not duplicated. As Ariola et al. 
[1995] describes, we can give a call-by-need semantics to 
£1 by weakening /3 to (iv and adding a garbage-collection 
rule that allows an unused let binding to be discarded. An 
analogous result holds in £2 : we can obtain call-by-need se- 
mantics by replacing <e> by <v> in the definition of values 
in Figure 7. 



5.2 £ 2 vs Haskell and ML ILs 

Our main theme is the search for an IL that can serve for 
both ML- and Haskell-like languages. However, we believe 
that a language like £ 2 is attractive in its own right to either 
community in isolation, because one might get better code 
from an £ 2 -based compiler. 

For the Haskell compiler writer £ 2 offers the ability to ex- 
press in its type that a value is certainly evaluated. This 
gives a nice way to express the results of strictness analysis: 
a function argument of unpointed type must be passed by 
value. Flat arrays and strict data structures also become 
expressible. 

for the ML compiler writer £•_> offers the ability to express 
the lad, that a computation is free from side effects, which 
is a precondition for a raft of useful transformations (Sec- 
tion 4.3). While this information can be gleaned from an 
effects analysis, maintaining this information for every sub- 
expression, across substantial program 1 ransformai ions is 
not easy. In £>. however, local transformations can per- 
form, and record the results of, a simple incremental effects 
analysis, for example, consider the following MI. function: 

fun f x = fst (fst x) 

Tf we translate this into £> we obtain: 

f = retgi (Ax. letgj a2 <- letgj aK-retgj x in 
retsT (fst al) 

ret ST (fst a2)) 
Simple application of the rules of Figure 3 allows this ex- 



pression to simplify to: 

f = retgj (Ax. let al = x in 

let a2 = fst al in 
ret ST (fst a2)) 

Now the retgx can be floated outwards, to give: 

f = ret ST (Ax.ret ST (fst (fst x) ) ) 

In this form, the inner ret ST makes it apparent that f has 
no side effects. We have, in effect, performed a sort of incre- 
mental effects analysis. The same idea can be taken further. 
If f is inlined at its call sites, then the retgT may cancel 
with let ST there, and so on. Even if f's body is big, we 
can use the "worker-wrapper" tec hnique of Peyton Jones & 
Lattnchbury [1991] to split f into a small, inlinable wrapper 
and a large, non-inlinable worker, fw, thus: 

f =ret ST (Ax.ret ST (fw x)) 
fw =Ax.(. . . body off...) 

Blume fc Appel [1997] describe a similar technique that they 
call "lambda-splitting" . 

The point of all this is that there is a real payoff for an 
ML compiler from making the ST monad explicit. Kasy, in- 
cremental transformations perform a local effects analysis; 
at each stage the state of the analysis is recorded in the 
program itself, rather than in some ad hoc. auxiliary data, 
structures; and all other program transformations will au- 
tomatically preserve (or exploit) the analysis. 



5.3 Parametric ity 

Polymorphic functions have certain parametricity properties 
that may be derived purely from their types (Mitchell & 
Meyer [1985]; Reynolds [1983]; Wadler [1989]). For example, 
in the pure polymorphic lambda calculus, a function / with 
type Va.a -> a — >■ a satisfies the theorem: 

VA, B . V/i : A -> B . Vx, y : A . h (/ x y) = f {h x) {h y) 

In fact, / satisfies something even stronger in which the 
function h can be an arbitrary relation between A and B. 

When we add "polymorphic" constants to the pure calculus, 
the effect is that the choice of functions h becomes restricted. 
For example, adding a fix point operator fix : Va.(a — ► a) — > 
a forces the restriction that the /; functions be strict (map A 
to A) and inductive (i.e. continuous). This is the situation 
in Haskell, for example. 

Adding polymorphic sequencing, say through an operator 
hcq : Vo. In .7 .7 or by building it into the seman- 
tics of function application, forces the restriction that the 
h functions be bottom-reflecting (i.e. defined on all defined 
arguments). This is the basic situation in pure ML. 

Adding polymorphic equality forces the h functions to be 
at least one-to-one: and adding polymorphic state opera- 
tions like !r seems to remove any last shreds of interesting 
parametricity. 

What, then, are the parametricity properties of £1 and £2? 
If parametricity properties are wea kened by claiming various 
primitives to be more polymorphic 1 han t hey really are, then 
by being more cautious in the types we assign them, we may 
hope to restrengthen parametricity. 
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In £2, for example, recursion is only done either at a func- 
tion type, or at a suspension type. Recursion is never per- 
mitted as a fully polymorphic type (unlike in Haskell). This 
has the effect of allowing the strictness side condition to 
be dropped, though inductiveness (or continuity) is ,ttfl re- 
quired. The same is achieved in £1 through the use of the 
pointed restriction (see Launchbury & Paterson [1996] for a 
comparable situation). Furthermore, since all state opera- 
tions are explicitly typed within the state monad, they also 
do not interfere with parametricity in a negative way. 

The main difference between £1 and £2 is to do with forcing 
evaluation. £1 has no polymorphic forcing operation, so has 
no consequent weakening of its parametricity property. £2 
does, however — it is built into its eager function applica- 
tion. Thus for £ 2 the parametricity theorem demands the 
h functions to be everywhere defined. 

To see an example of this, consider the function A" : 
Va,/3.o -> (3 -> a which selects its first argument, discarding 
its second. The parametricity theorem is 

VA,A',B,B' . Vfti : A ->• A' ,h 2 : B ->■ B' . Wx : A,y: B . 
h 1 (Kxy) = K (hi x) (ftj y) 

Clearly this holds only if h 2 is total (defined everywhere), 

left hand side is. 

There is a pract ieal implieal ion to this. A class of techniques 
for removing intermediate lists called foldr-build relies on 
parametricity for its correctness (Gill, Launchbury & Pey- 
ton Jones [1993]). While a strictness side condition is not 
damaging, a totality condition is too restrictive. The tech- 
nique can no longer rely on the types to provide sufficient 
guidance for correctness. This is disappoint ing. although 
unsurprising. The compiler can still recover the short-cut 
deforestation technique by refining £2 5 s type system to use 
qualified types along the lines of Launchbury &: Paterson 
[1996]. 



5.4 Side effects and polymorphism 

It is well known that the ability to create polymorphic ref- 
erences can lead to unsoundness in the type system (Tofte 
[1990]). For example, if we are able to create a reference 
r with type Va.Ref a then we would be able to write the 
following erroneous code: 

let S T -:() <-wr (r Int) 2 in 

let S T f : (Int->Int) <-rd (r (Int->Int)) in 

ret ST (f 3) 

However in both £, and £2 any expression of type Vn.Ref n 
is undefined in any environment! The only way to construct 
a value of Ref type is with new, which returns a value of type 
ST (Ref t). The only way to strip off the ST constructor is 
with letgx- Looking at the typing rule for letg-r, we can 
see thai, bound variable must have type Ref r. 

SML's so-called "value restriction" conservatively restricts 
generalisation in let bindings precisely to avoid the con- 
struction of such polymorphic references. We conjecture 
(though wo have not proved) that C\ and £■_> are both sound 
without any such side conditions. 



5.5 ML t hunks 

One of the advantages of a language that supports both 
strict and lazy evaluation is 1 hat it can accommodate source 
languages that have such a mixture. Indeed, it is quite 
straightforward to map Haskell's strictness annotations (Pe- 
terson et al. [1997]) onto £ 2 . Coming from the other direc- 
tion, it has long been known that t hunks can be encoded 
explicitly in a strict, imperative language. For the sake of 
concreteness we use the notation proposed for ML in Okasaki 
[1996]. In this proposal delayed ML expressions are prefixed 
by a "$", thus: 

let val x = $(f y) in b end 

Here, assuming (f y) has type int, x is bound to a thunk 
of type int susp that, when forced, evaluates (f y) and 
overwrites the thunk with its value. 

We expected that these "ML t hunks" would map directly 
onto £2's thunks, but that turned out not to be the case. 
The semantics of ML thunks is considerably more compli- 
cated than that of £/s thunks. because of the interaction 
with state. Consider the following ML expression: 

let val rec x = $(let val y = !r - 1 in 
r:=y; 

if y=0 then 0 

else force x + force x 
end) 

(This defines x recursively, which is not possible in ML, but 
essentially the same thing can be done using another refer- 
ence to "tie the knot" . We use the recursive form to reduce 
clutter.) When x is evaluated it decrements the contents of 
the reference cell r; but then, if the new value is non-zero, 
x evaluates itself! In effect, there can be multiple simulta- 
neous activation* of x. rather like the multiple activations 
of a recursive function. (Indeed, a non-memoising imple- 
mentation of ML thunks can be obtained by representing $e 
by AQ.e.) Furthermore, these multiple activations can each 
have a different value, because they each read the state. 

£2's thunks have a much simpler semantics. A thunk has 
only one value, and there can be at most one activation 
of the thunk 7 . The key insight is that evaluation of a £2 
thunk has no side effects, unlike the ML thunk above. But 
what if the contents of the thunk performs side effects? For 
example: 

let x = <let ST v : Int <- rd r in wr (v+1) > in e 

Here, if r : Ref Int, then x has type <ST ()>, not <()>. 
Forcing the thunk (with force) causes no side effects (apart 
from updating the thunk itself), and yields a. computation 
thai . when subsequently performed (by a letg-r), will incre- 
ment the location r. The computation x may be performed 
many times; for example, e might be 

let ST al : () <- force x in let ST a2 : () <- force x in ... 

What this means, though, is that the more complicated se- 
mantics of ML thunks have to be expressed explicitly in £ 2 , 
presumably by coding them up using explicit references. 

7 More precisely, if there is more than one then the thunk's value 
depends on its own value, so its value is undefined. This property 

to avoid space leaks and to report certain non-termination (Jones 
[1992]). 
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6 Related work 



The FLINT language has rather similar objectives to the 
work described here, in that it aims to serve as a common 
infrastructure for a variety of higher-order typed source lan- 
guages (Shao [1997b]). However, FLINT has not (so far) 
concentrated much on the issue of strictness and laziness, 
which is the main focus of this paper. The ideas described 
here could readily be incorporated in FLINT. 

Both the Glasgow Haskell Compiler and the TIL ML com- 
piler use a polymorphic strongly-typed internal language, 
though the latter is considerably more sophisticated and 
complex (Peyton Jones [1996]; Tarditi et al. [1996]). Nei- 
ther, however seriously at .tempt to compile the other's main 
evaluation-order paradigm. 



7 Further work 



In this paper we have concentrated on a core calculus. Some 
work remains to extend it to a practical IL: 

• Recursive data types and case expressions must be 
added — we anticipate no difficulty here. 

• A proof of type soundness is needed. As we note in 
Section 5.4 its soundness is not obvious. 

• We have a simple operational semant ics for £■>: we are 
confident that it is sound and adequate, but have yet 
to do the proofs. 

• We are studying whether is is possible to combine £i's 
ability to describe certainly-terminating computations 
with £2's operational model. 

Accommodating the ML module system is likely to involve 
a significant extension of the type syst em (Harper & Stone 
[1997]); we have not yet studied such extensions. 

In a separate paper we discuss how to use the framework of 
Pure Type Systems to allow the language of terms, types, 
and kinds to be merged into a single language and compiler 
data, type (Peyton Jones k Meijer [1997]). W e hope to merge 
the results of that paper and this one into a single IL. 

We have made no attempt to address the tricky problem 
of how to combine monads. For example, ML includes the 
monad of state and exceptions. Is it advantageous to sepa- 
rate them into the composition of two monads, or is it better 
to have a single, combined monad? In the former case, what 
transformations hold? 

An important operational question is that of the represen- 
tation of values, especially numbers. Quite a few papers 
have discussed how to use unboxed representations for data 
values, and it would be interesting to translate their work 
into the framework of £•_> (Lerov [1992]: Pevtoti Jones i.: 
Launchbury [1991]; Shao [1997a]). 
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